home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1996 #14 / Monster Media No. 14 (April 1996) (Monster Media, Inc.).ISO / prog_c / fdiv.zip / FDIV.TXT
Text File  |  1996-01-19  |  5KB  |  175 lines
  1. This file contains information explaining the workaround that
  2. Microsoft has implemented in their compiler and run-time library
  3. for the Intel Pentium processor's which contain a potential flaw
  4. in four instructions.
  5.  
  6.  
  7. ----------
  8. Compiler
  9.  
  10. By default, the compiler generates safe code for FDIV and FPREM.
  11. Hooks are also provided for (user-written) replacements for FPTAN and
  12. FPATAN.
  13.  
  14. Uses of the flawed instructions in inline-assembly code are flagged
  15. (warning C4725, -W4) but not corrected by the compiler. Safe runtime
  16. routines for a single, flexible form of the FDIV and FPREM instructions
  17. are provided to aid manual user conversion of the code to the safe form
  18. (see the "Runtimes" section below).
  19.  
  20. The compiler generates the above-mentioned safe (or replacable) sequences
  21. by default. You can turn off the fix by using the compiler option "-QIfdiv-".
  22.  
  23. ----------
  24. Runtimes
  25.  
  26. The following runtime routines are provided. The names given here are
  27. C names; prefix the name with an underscore ( _ ) to get the "true"
  28. assembler/OBJ name.
  29.  
  30.     _adjust_fdiv -- Flag which tells if there is a 'flawed' Pentium installed.
  31.     Used to 'short-circuit' calls to the safe routines in speed-critical
  32.     sections of code.
  33.  
  34.     e.g. of use:
  35.         ...
  36.         pushfd            ; save flags (if needed)
  37.         fld    op1        ; load dividend
  38.         fld    op2        ; load divisor
  39.         cmp    __adjust_fdiv,0    ; 0=ok, !0=flawed
  40.         jeq    ok        ; brif ok
  41.         call    __safe_fdiv    ; safe version
  42.         jmp    done
  43.         ok:
  44.         fdivp    st(1),st(0)    ; hdwr version
  45.         done:
  46.         ; either way, args gone, result on top of NDP
  47.         popfd            ; restore flags
  48.         ...
  49.  
  50.     Alternately one could just always call the safe version
  51.     (slower, but safe):
  52.  
  53.         pushfd            ; save flags (if needed)
  54.         ...
  55.         fld    op1
  56.         fld    op2
  57.         call    xxx_fdiv
  58.         ...
  59.         popfd            ; restore flags
  60.  
  61.     _safe_fdiv -- safe divide routine
  62.  
  63.     Interface is same as for the x87 NDP 'FDIV' instruction
  64.         (aka FDIVP ST(1),ST(0))
  65.  
  66.     Takes two arguments on the NDP, pops them, does divide, pushes result
  67.     onto NDP.
  68.  
  69.     Routine does 'safe' version of divide.
  70.  
  71.     _safe_fdivr -- safe reverse divide routine
  72.  
  73.     As for _safe_fdiv, but does reverse operation.
  74.  
  75.     Interface is the same as for the x87 NDP 'FDIVR' instruction
  76.         (aka FDIVRP ST(1),ST(0))
  77.  
  78.     _safe_fprem -- safe remainder routine (x87 compatible)
  79.  
  80.     As for _safe_fdiv, but does remainder.
  81.     
  82.     Interface is the same as for the x87 NDP 'FPREM' instruction.
  83.  
  84.     _safe_fprem1 -- safe remainder routine (IEEE conformant)
  85.  
  86.     As for _safe_fdiv, but does IEEE remainder.
  87.  
  88.     Interface is the same as for the x87 NDP 'FPREM1' instruction.
  89.  
  90.     _adj_fptan -- unsafe tangent routine (replacable)
  91.  
  92.     As for _safe_div, but (n.b.!!!) provides hooks only; does *not* do a
  93.     Safe version.
  94.  
  95.     Interface is the same as for the x86 NDP 'FPTAN' instruction.
  96.  
  97.     Users who want a safe version must replace this routine with one of
  98.     their own.
  99.  
  100.     _adj_fpatan -- unsafe arctangent routine (replacable)
  101.  
  102.     As for _adj_tan, but does atan.
  103.  
  104.     Interface is the same as for the x86 NDP 'FPATAN' instruction.
  105.  
  106.     Note: Does *not* do a safe version.
  107.  
  108. In summary:
  109.  
  110.     routine        safe?    replacable?
  111.     -------        -----    -----------
  112.     _adjust_fdiv    n/a    n/a
  113.     _safe_fdiv    y    y
  114.     _safe_fprem    y    y
  115.     _safe_fprem1    y    y
  116.     _adj_fptan    n    y
  117.     _adj_fpatan    n    y
  118.  
  119.  
  120. ----------
  121. Performance
  122.  
  123. Performance of FDIV on the following two interesting cases:
  124.  
  125. -- Worst Case: an (unrealistic) program which did nothing but FDIVs ran
  126. -- Realistic Case: FPSpec, a set of FP-intensive programs
  127.  
  128. is as follows:
  129.  
  130.     - Worst Case:
  131.             flawed pentium    good pentium
  132.     unsafe code        (error)        1.0
  133.     safe code        2.0        1.1
  134.  
  135.     - Realistic Case:
  136.             flawed pentium    good pentium
  137.     unsafe code        (error)        1.0
  138.     safe code        1.10        1.01
  139.  
  140. In other words, the (extremely unlikely) worst case penalty is 10% on a good
  141. Pentium, 2x on a flawed Pentium; and the realistic penalty is <1% on a
  142. good Pentium, and 10% on a flawed Pentium.
  143.  
  144. As always, "Your mileage may vary."  That is, you may see no slowdown in a
  145. realistic program, or you may see 2x in a realistic program.  If performance
  146. is an issue for you, measure it and see what your actual results are.
  147.  
  148. ----------
  149. CAVEAT:
  150.  
  151. We have tested this fix extensively.  However, as with all software, there is
  152. always a possibility that bugs remain.  We assume that customers will rigorously
  153. test their applications to ensure correctness.
  154.  
  155. Accuracy of floating point operations is a complex subject.  Even with an
  156. accurate set of 'atomic' operations, such as +,-,*,/,  a program can give
  157. unexpected results.  The C/C++ standard does not in general guarantee
  158. a specific order of evaluation for expressions, nor does it guarantee that
  159. intermediate results will be forced to a particular precision, so two programs
  160. that are logically equivalent on the surface may yield different results.
  161.  
  162. For a more detailed discussion of some of the above, see:
  163.  
  164.     Visual C++ documentation, "-Op" compiler option
  165.     IEEE Floating-Point Standard
  166.     C Language Standard
  167.  
  168. The first of these references is probably the most readable overview.
  169.  
  170. Most people need not worry about this, either because they do not use floating point at
  171. all, or because they do not need an extremely high degree of accuracy.  Those
  172. that do need to worry are urged to make sure they understand the issues rather than
  173. blindly assume that the tools will "just work."
  174.  
  175.